REMARKS 



This paper is responsive to an Office Action mailed July 11, 
2008. Prior to this response, claims 1, 6-15, 20-26, 31-40, and 45-50 were 
pending. Claims 1, 6-15, 20-26, 31-40, and 45-50 remain pending. 

In Section 2 of the Office Action claims 1 and 6-14 have been 
rejected under 35 U.S.O. 103(a) as unpatentable with respect to Admitted 
Prior Art (APA) in view of Herpel, "Elementary Stream Management in 
MPEG-4, IEEE, March 1999 fHerper) and Waki et al. ("Wakf^ EP 
1045564). With respect to claim 1, the Office Action states that the APA 
discloses using a lid URI to retrieve MPEG-4 resources in an MPEG-2 TS. 
The Office Action acknowledges that the APA fails to use lid URIs to 
provide a binding name and access scheme to objects in the OC, but that 
Herpel and Waki disclose this feature. This rejection is traversed as 
follows. 

lOR, BIOPProfileBody and NSAP are address schemes 
specified in the DSM-CC specification to uniquely identify an object in an 
Object Carousel (00). DSM-CC is a part of MPEG-2 (Part 6), and a DSM- 
CO OC and it's defined address structure schemes (such as lOR, NASP, 
etc.) can be used to carry any kind of data including MPEG-4 files, JPEG 
fiiles, or Microsoft word documents, to name a few examples. Further, a 
DSM-CC OC can be used to build a hierarchical directory structm-e to 
carry these types of data. 

In contrast, a MPEG-4 system is built around an Initial 
Object Descriptor (lOD), no matter if it is carried over MPEG-4 File 
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Format, IP, or any kind of transport. lOD is the entiy gateway of the 
MPEG-4 system, from which all other elementary streams (ES) such as 
scene, video, audio, are linked together. In the MPEG-4 specification, 
there are only two linkage (reference/address) methods defined, one is 
called elementary stream identifier (ES-ID), the other is URL. The 
specification does not permit any other address scheme. An ES-ID is 
unique to each ES, so a decoder can find the ES in the transport stream by 
identifjdng its ES-ID. A URL is also unique. The claimed invention uses 
alid type of URL/URL 

Therefore, although a DSM-CC OC can carry MPEG-4 data, 
the data is not carried in accordance with the MPEG-4 specification, 
DSM-CC does not provide a way to encode or decode MPEG-4 resources. 
Alternately stated, MPEG-4 specification does not mention or permit any 
specific DSM-CC address schemes such as lOR or NSAP addresses. Only 
ES-ID and URL/URI address schemes are permitted for 
encoding/decoding. 

The claimed invention describes a system that carries data in 
an MPEG-2 DSM-CC 00. However, the use of a lid URI permits an 
MPEG-4 to encode or decode MPEG-4 data in the OC. That is, the use of 
a lid URI decouples the addressing (binding) scheme from the one defined 
by the DSM-CC, which includes lOR, NSAP, etc. In fact, it doesn't matter 
what addressing scheme the DSM-CC uses, as long as the lid URI 
linkages are present. A URI based hierarchical directory structure is as 
shown below (Fig. 7 of the specification). Each object is referenced by a lid 
or http URI (some are referenced both by a http and a lid). Each object 
also has a NSAP address because it is an object in the DSM-CC OC. 
However, only the base URI need be associated with an NSAP addi*ess in 
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the DSM-CC OC, Once the linkage is created, the rest of the objects can 
be referenced relatively in the OC. Note however, that a NASP address is 

not the same as a URI address. Likewise, the address schemes are 
different. However, an object may have an address in both schemes. 



As noted in the Applicant's specification (paragraph [0118]), 
a lid URI is defined in accordance with SMPTE 343M-2002, as follows: 

A lid: can be bound to a resource entity during 
authoring and distribution, and may be used to name a 
device-independent storage location for the entity. The lid: 
scheme is syntactically similar to the http: scheme, but it is 
not intended to resolve lid: identifiei'S to locations outside the 
broadcast stream or local storage system, as is the case for 
http: DNS and resoiirce resolution. 

A complete copy of SMPTE 343M-2002 is enclosed as 
Attachment A, 



The APA presents details of conventional MPEG-4 and 
MPEG-2 protocols, citing paragraphs 0006-0015. Paragraphs 0006 hsts a 
number of protocols closely related to MPEG-2, and notes that the 
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carnage of MPEG-4 data using MPEG-2 transports is a problem yet to be 
solved. 

Paragraph 0007 states that ISO/IEC 13818-1 describes a 
FlexMux encapsulation scheme (see Herpel, Fig. 8). The MPEG-4 content 
is referenced using a Program Map Table (Table 1, [0008-0014]), The 
Progi'am Map Table does not list a hd URI, or the use of a Hd URI to 
access MPEG-4 data in an MPEG-2 TS. 

Beginning at [0015], the APA describes the procedure for 
playing MPEG-4 content. lODs are mentioned, which contain 
ES^descriptors for BIFS scene and object descriptor streams. Paragraph 
[0019] states that a URL in a ES-Descriptor can be used to specify a 
location from which a BIFS stream can be retrieved. The above-cited 
paragraphs do not disclose an MPEG-2 TS embedded with MPEG-4 
organized in an 00 or DSM-OC U-U. As noted above, a conventional 
MPEG-4 system does not encode or decode MPEG-4 resouixes in a DSM- 
CO 00. Further, the APA makes no mention is made of a lid, and no 
mention is made of a lid being used to locate a URI in a MPEG-2 TS, 

In Section IV 0 (page 321) Herpel states that MPEG-2 TSs 
may be used to encapsulate MPEG-4 streams. Three approaches are 
presented on page 322 for encapsulating MPEG-4 streams in an MPEG-2 
TS, they are: 1) Single Stream Encapsulation; 2) FlexMux Stream 
Encapsulation; and, 3) Digital Storage Media, Herpel states that Single 
Stream Encapsulation method is inefficient (pg 322). Herpel states that 
the FlexMux mapping to a PID can be used to x'educe bandwidth. The 
Applicant notes that neither the Single Stream nor FlexMux method use a 
URI. and more particularly a lid URI to locate, access, or retrieve MPEG-4 
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resources from an MPEG-2 TS. Finally, Herpel describes using a DSM- 
CC carousel for embedding MPEG-4 resources in an MPEG-2 broadcast. 
The advantage of the approach is that several SL-packetized ESs can be 
multiplexed into one PID. However, the disadvantage is that the DSM- 
CC data carousel must be regularly repeated to allow random tune-in. 
Herpel doubts that this enormous waste of bandwidth will be tolerated 
by service providers " As noted above, there are only 2 MPEG-4 
addressing schemes: ES-ID and URL. Herpel does not disclose a method 
of using lid URIs to provide a binding name and access scheme to objects 
in the 00. In fact, Herpel appears to be describing an ES-ID system, and 
HerpeVs "regular repeating" method points away from the recited use of 
lid URIs to locate resources. Alternately stated, although Herpel states 
that MPEG-4 data can be carried in a DSM-CC 00, he provides no 
linkage between the lOD needed in an MPEG-4 system for 
encoding/decoding, and the DSM-CC 00. In the claimed invention, the lid 
URI provides a linkage between the MPEG-4 and MPEG-2 (DSM-00) 
systems. 

Waki, in paragraphs [0006-0010] describes a conventional 
MPEG-2 DSM-00 protocol. No mention is made in the cited paragraphs 
of using the DSM-00 protocol for the carriage of MPEG-4 data. In 
paragraphs [0017-0019], Waki presents definitions for I0P::I0R and 
BIOP. The cited paragraphs do not describe the carriage of MPEG-4 data 
in an MPEG-2 TS, a URI, a Ud URI, or retrieving MPEG-4 resources from 
an MPEG-2 TS by using a lid URI to provide a binding name and access 
scheme to objects in an 00. Paragraphs [0132] describes a BI0P::Binding 
structure. Paragi-aph [0136] describes Fig. 28, BIOP defining "objectinfo". 
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Paragraph [0137 describes Fig. 20, definition of BIOP. [0138] describes 
the direct directory message body in Fig. 20. [0139] describes the 
insertion of a direct directory message into the "objectinfo" in the BIOP. 
The direct directory message body is shown in Fig. 6, objects are shown in 
Figs. 4-5, and directoiy objects are shown in Figs. 21-22. [0140] describes 
Fig. 23, a flowchart of the transmitter apparatus 300, 

The AppHcant notes that the cited sections fail to disclose the 
exact tems or the general concepts of a URI or lid URI. Thus, the cited 
section necessarily fails to describe using lid URI to provide a binding 
name and access scheme to objects in an OC. In fact, the Waki reference 
fails to even mention to term "MPEG-4'\ and does not describe a means of 
carrying MPEG-4 resources in an MPEG-2 TS. The Waki reference 
appears to have absolutely no relevance to the claimed invention. 

The Response to Arguments Section of the Office Action 
states that Waki's lOR is the equivalent of a lid URI, as the lOR contains 
a BIOPProfileBody - all the information pertaining to an object that is 
needed to uniquely needed to identify the object and locate it within a 
Service Domain specified by an NSAP address. However, as explained in 
detail above, while NSAP addresses have relevance in DSM-CC, this type 
of addressing scheme does not permit encoding or decoding in accordance 
with the MPEG-4 specification. More important, Waki does not describe a 
means for an MPEG-4 system to gain access to the NSAP addresses. The 
claimed invention provides this linkage through the use of a lid URL 

Unlike the more conventional page or http address URI, 
which is commonly referred to as a URL, the claimed invention recites a 
narrowly prescribed version of a URI - a local identifier (lid). Unlike a 
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URI (URL) that points to a web address, or a URI that points to an 
address in memory, a lid URI permits resources to be referenced in a 
broadcast message. Alternately stated, a lid URI has the unique ability to 
label resources that are only available in a broadcast scheme. The use of 
an MPEG- 2 DSM-CC U-U Object Carousel is not new. However, the use 
of a lid URI to create a Unkage between MPEG-4 and DSM-CC systems is 
novel. 

None of the references disclose using a local identifier Oid) to 
locate a URI in the MPEG-2 TS. In fact, none of the references mention 
the term *lid", or any functional equivalent. Finally, none of references 
retrieves MPEG-4 data fi:om an MPEG-2 TS by using lid URIs to provide 
a binding name and access scheme to objects in the OC, The APA and 
Herpel describe a FlexMux method of carrying MPEG-4 data in an MPEP- 
2 TS. Herpel also mentions Single Stream and DSM-CC methods. 
However, none of the references use a lid to retrieve MPEG-4 resources by 
providing a name/access scheme to DC objects. 

Therefore, even if all three references are combined, the 
combination does not include every limitation recited in the claimed 
invention. Neither is there a suggestion to modify references in such a 
way as the make the claimed invention obvious, since none of the 
references describe the use of a lid URI, or how a lid URI can be used to 
access MPEG-4 resources in an MPEG-2 TS, Finally, no evidence has 
been provided that the use of a lid URI was well known to practitioners in 
the art, for the carriage of MPEG-4 data in an MPEG-2 TS. 

The combination of refei-ences neither explicitly discloses all 
the limitations of claim 1, nor suggests modifications that would make the 
missing limitations obvious. Claims 6-14, dependent from 1, enjoy the 
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same distinctions, and the Applicant requests that the rejection be 
removed. 



In Section 3 of the Ofifice Action claims 15 and 20-39 have 
been rejected under 35 U.S.C. 103(a) as unpatentable with respect to the 
APA in view of Herpel and Waki, and further in view of Yokomizo (US 
2002/0124263. With respect to claims 15 and 26, the Office Action states 
that the APA/Herpel/Waki fails to disclose embedding a URI in a 
broadcast MPEG-2 TS, but that Yokomizo discloses this feature. This 
rejection is traversed as follows, 

Yokomizo discloses a system that transmits MPEP-2 data 
with a BIFS object, which appears as a button on a viewer's screen. The 
button is linked to a URL. When the viewer "pushes" the button, a 
connection is made by HTTP protocol to the viewer's set top box, and a 
synch layer is set for an MPEG-4 stream transmission [0030-0034], As 
noted above a URL that accesses a web address can be differentiated from 
a lid URI that accesses information in a broadcast data stream. Yokomizo 
does not disclose embedding MPEG-4 resources in an MPEG-2 stream 
using an OC transport protocol^ or using lid URIs to provide a binding 
name and access scheme to the objects in the OC. 

None of the foxxr references disclose using a local identifier 
(lid) to locate a URI in the MPEG-2 TS. None of the references mention to 
term 'lid", or any functional equivalent. None of references retrieves 
MPEG-4 data from an MPEG-2 TS by using lid URIs to provide a binding 
name and access scheme to objects in the OC. Thei-efore, even if all four of 
the references are combined, the combination does not include every 
limitation recited in the claimed invention. Neither is there a suggestion 
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to modify references in such a way as the make the claimed invention 
obvious, since none of the references describe the use of a Hd URI, or how 
a lid URI can be used to access MPEG-4 resources in an MPEG-2 TS, 
Finally, no evidence has been provided that the use of a lid URI was well 
known to practitioners in the art, for the carriage of MPEG-4 data in an 
MPEG-2 TS, as recited in claims 15 and 26. Claims 20-25, dependent 
from 15, and claims 31-39, dependent from claim 26, enjoy the same 
distinctions, and the Applicant requests that the rejection be removed. 

In Section 4 of the Office Action claims 40 and 46-50 have 
been rejected under 35 U.S.G. 103(a) as unpatentable with respect to the 
APA in view of Yokomizo, and further in view of Ito et al. ("Ito:, US 
6,377,309. With respect to claim 40, the Office Action states that 
Yokomizo fails to disclose embedding an MPEG-4 encoder, but that Ito 
discloses this feature. This rejection is traversed as follows. 

Ito does not disclose embedding MPEG-4 resources in an 
MPEG-2 stream using an 00 transport protocol, or using lid URIs to 
provide a binding name and access scheme to the objects in the 00. 

Even if Ito's encoder is combined with Yokomizo and the 
APA, none of the references disclose using a local identifier (lid) to locate a 
URI in the MPEG-2 TS. None of the references mention to term "lid", or 
any functional equivalent. None of references retrieves MPEG-4 data 
from an MPEG-2 TS by using lid URIs to provide a binding name and 
access scheme to objects in the 00. Therefore, even if all the references 
are combined, the combination does not include every limitation recited in 
the claimed invention. Neither is there a suggestion to modify references 
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in such a way as the make the claimed invention obvious, since none of 
the references describe the use of a lid URI, or how a Hd URI can be used 
to access MPEG-4 resouxxes in an MPEG-2 TS. Finally, no evidence has 
been provided that the use of a lid URI was well known to practitioners in 
the art, for the carriage of MPEG-4 data in an MPEG-2 TS, as recited in 
claim 40. Claims 46-50, dependent from 40, enjoy the same distinctions, 
and the AppHcant requests that the rejection be removed. 
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It is believed that the application is in condition for 
allowance and reconsidexation is earnestly solicited. 



Respectfully submitted, 



Date: 8/27/2008 /Mali/ 

Gerald Maliszewski 
Registration No. 38,054 

Customer Number 55,286 

P.O. Box 270829 

San Diego, CA 92198-2829 

Telephone: (858) 451-9950 

Facsimile: (858) 451-9869 

gerrv@ipatentit.net 
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1 Scope 

This standard defines the lid: uniform resource iden- 
tifier (URI). and describes how it is used to identify 
instances of resources, such as web pages and 
graphics files, that are transmitted through unidlreo- 
tional nrieans, such as a television broadcast. 

2 Normative references 

The following standards contain provi^ons which, 
through reference in this text, constitute provisions of 
this standard. At the time of publication, the editions 
indicated were valid. All standards are subject to 
revision, and parties to agreements based on this 
standard are encouraged to investl^te the possibility 
of applying the most recent edition of the standards 
Indicated below. 

IETF RFC 2396. Uniform Resource Identifiers (URI): 
Generic Syntax 

ISO/IEC 11578:1996, Information Technology ~ 
Open Systems Interconnection Remote Procedure 
Call (RFC). Annex A, Universal Unique Identifier 



3 Introduction 



Content resources delivered by a one-way broadcast 
must be identified, stored in a storage system used by 
the receiver as they are received, and referenced by 
a uniform scheme for access by applications and 
systems. Broadcast receivers may use different types 
of storage devices; therefore, content broadcasters 
and application developers need a standard syntax 
for resource storage and reference that does not 
depend on the specific device or directory syntax, 
su<^ as the file: URI scheme. A lid: can be bound to 
a resource entity during authoring and distribution, 
and may be used to name a device-Independent 
storage location for the entity. The lid: scheme is 
syntactically similar to the http: scheme, but it is not 
intended to resolve lid: identifiers to locations outside 
the broadcast stream or local storage system, as is 
the case for http: DNS and resource resolution. 

The lid: URI scheme enables content aeators to 
assign an authority value thai is globally unique. The 
lid: scheme supports relative paths for resource re- 
trieval, so the authority component can be separately 
identified in applications to allow relative path refer- 
ences similar to http: and other URI references. 

A single lid: can be used to identify different resource 
Instances over time, and will resolve in a receiver to 
the last instance received with an equivalent lid:. 
Appropriate lid: identifiers can reduce the storage of 
redundant instances of resources for better memory 
efficiency. Storage management for lid: entities is 
Implementation specific and beyond the scope of this 
specification, but It can be assumed that memory will 
be finite, and so will the period of persistence of any 
lid: entity. Applications using lid: should be designed 
to handle the case where resources have been de- 
leted over time due to storage limrtations. 
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4 Definition of local identifier (lid:) URI 
scheme 

The lid: URI scheme describes URI references corv 
sisting of a sequence of characters which are inde- 
pendent of their coding in octets in any particular 
character set. The lid: URI fully complies with IETF 
RFC 2396 except for the overloading of the authority 
field in the deprecated form. 

The layout of the lid: URI follows the generic URI 
syntax: 

lidy/<ifierfrfc>@4t)st>>^^ 

Usennfb is an optional string that enat^es message 
ID syntax fomns of the authority field and, in combina- 
tion with the host field, complies with the mid: scheme 
syntax defined in IETF RFC 2392. 

Host is a string whose root is a registered domain 
name or a uuld (ISQ/IEC 11578) in string form. Note 
that the uuid fonm is deprecated and is intended to 
support past common practice. 

Port is a string to allow syntactic compatibility with 
IETF RFC 2616 and has no semantic meaning. 

Path is a slash-separated string of components iden- 
tical to the http: scheme syntax as defined in IETF 
RFC 2616. 

Query and fragment are content-type dependent 
strings compliant with IETF RFC 2396, 

Relative path syntax, as described In section 3 of 1 ETF 
RFC 2396 is also permitted syntactically, but must 
only be used in cases where there is a guaranteed 
mechanism to resolve the absolute path (i.e., the 
BASE URI is well defined). Practical delivery consid- 
erations may require that lid: identified resources be 
delivered on broadcast channels using absolute paths 
to enable real-time storage in sequence of resource 
amval, but relative path resolution must be supported 
for lid: resource retrieval, assuming an application 
spedfies the base of ttie URI by other means. 

The following are examples of lid:s: 

6dyMx:xx)mEveningNews^11-Maich-0iyPac^^ 

\\&J(AF4^ 82C71 C1 FDD4BA0937A7EB7B8B4C 1 @ 
mail.xbc.com 



A deprecated fonri of usage is to pemiit host to be an 
encoded UUID (ISO/IEC 11576). While technically the 
UUID name space overlaps the domain name space, 
in practice a collision is entirely improbable. Examples 
of this deprecated fonm using UUID are: 

lid://4F4 1 82C7 1 C1 FDD4BA0937A7EB7B8B4C1 / 

images/logo.gif 

Iid7/4F41 82C7-1 CI F-DD4B-A093-7A7EB7B8B4C1 / 
images/logo.gif 

The UUID Is represented as an ASCII hex coding 
resulting in 32 characters. Note that two syntaxes are 
penmitted — one with some spedfically placed sepa- 
rating hyphens and one without (see thei BNF defini- 
tion below). 

When different resources are received wth matching 
lid:s. the most recently received resource should be 
referericed using that lid:. Thus a lid: n^y refer to 
different resources over time. One lid: UR! can bQ 
assigned for all instances of a resource; or multiple 
unique URIs can be assigned, one for each instance 
of the resource. 

5 Resolution rules 

A lid: URI Is used to label a resource. Certain parts of 
the URI are ignored for the purposes of comparison, 
when the lid: is used for retrieval, or to replace a 
previously transmitted resource with an equivalent 
URI. When testing for equivalence, the query and 
fragment Identifiers (I.e., characters in the lid: includ- 
ing and following the first ? or # <^aracter) in a lid: URI 
are ignored. Notwithstanding, references using frag- 
ment and query identifiers may function in ways de- 
fined by the content type bj^ng referenced. 

When comparing two URIs to decide if they match or not, 
a receiver should use a case-sensitive octet-by-octet 
comparison of the entire URIs, with these exceptions: 

- A port that is empty or not given is equivalent to 
the defiault port for ht4>:, which is 80; 

- Comparisons of host names shall be case inserv- 
sitive; 

- Comparisons of scheme names shall be case 
insensitive; 

-Anemptyabs j>athisequvalenttoanabsj3athof/. 
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Characters other than these in the reserved and un- 
safe sets (see IETF RFC 2396) are equivalent to their 
% HEX HEX encoding. For example, the following 
three URIs are equivalent: 

lid ://alx:.com:80/-snnith/home.html 

lid'7/ABC.com/%7Esmith/home.html 

lld.//ABC.com:/%7esnfuth/honne;html 

Unlike http:. a lid: URI is not locatable without more 
infomiation and is thus URN-like In the generic defini- 
tion in that a URN is associated to a resource and 
independent of the resource's location. Therefore, the 
details of resolution of the location of a (id: is applica- 
tion dependent 

6 Normalization and equivalence 

In nnany cases, different URI strings n^y actually 
identify the same resource. For example, the 
host names used in the URL are case insensitive, 
so the URL <lid://www.XBC.com> is equivalent to 
<1id:/AA/ww.xbc.com>. In general, the rules for equiva- 
lence and definition of a normal form, if any are 
sdieme dependent. When a scheme uses elements 
of the common syntax, it will also use the common 
syntax equivalence njles; namely, that the scheme 
and hostname are case insensitive and a URL with an 
explicit :port where the port is the defiault for the 
scheme, is equivalent to one where the port is elided. 

7 Locaildentifier syntax BNF 

The collected BNF for lid: URts is as follows: 

lid = lid" rvr authority (al)sj>ath][T query] 
[•Tfragment] 

authority ^ server | uuid 



server » as defined In RFC 2396 
absjpath = as defined in RFC 2396 
query = as defined in RFC 2396 • 
fragment = as defined in RFC 2396 
uuid - uuid.simple | uuidjdl 
uuid^simple » 32hex 

uuidjdl - 8hex"-"4hex*-.Mhex"-"4hex"-" 
12hex 

hex s as defined in RFC 2396 

NOTE - The notation <n> (element) means exactly <n> 
occunrences of (element): e.g.. 32h0x means exactly 32 hex 
digits. Use of the uuid authority element is deprecated. 

6 Security considerations 

The local identifier URI scheme is subject to the same 
security implications as in general URI schemes, so 
the usual precautions apply This means that some 
local identifier URIs may refer to resources that are 
not available (because they have not been received, 
for example), or to resources that have been received 
but were intentionally misidentified. The security is- 
sues associated with this mislab^ing, as well as the 
secunty issues associated with the use of HTML 
content which is broadcast, are the same as those 
identified in section 11 .1 of IETF RFC 2387. 

Appropriate security mechanisms should be used in 
the delivery of content identified by lid: URIs. These 
indude protection of the broadcast signal by data 
encryption and conditional access methods, and pn> 
taction of content prior to broadcast so that invalid lid:s 
are not created, and valid lid:s are not modified. 
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Annex A (informative) 

Converting other URI schemes to lid: 



URL references using schemes such as http:, ftp:, and fife: 
cen be converted to valid by changing the scheme 
component and using the original name, host, path, frag- 
ment, and query components. This is use^l. for instance* to 
deliver resources stored on Internet servers over a broad- 
cast channel. Note that the original URL port and password 
fleids have no semantic definition in lid:. 



and that resource identifier could be used to store the 
text.txt entity in memory with a derived directory entry, which 
would be matched by the foUowing lid: reference in an HTML 
document 



could be packaged In a broadcast stream with a header 
containing the resource Identifier 



lid ://www j(bc.com/tv Aext . txt 



Example: 



An Internet resident resource at the location 



hrel'^lid://www jcbc.com/tv/text. bctVIQsmyProgram 



http://www.xbc.com/tv/text.txt 



« 
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